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The invention of the above-identified application was "reduced to practice* at least as " 
eaiiy as one day prior to September 14, 1998, 

The undersigned inventor personally wrote and then submitted on January 22, 1998, to 
Siemens AG (attention Mr. Hassa), assignee of the subject invention, an invention disclosure 
entitled "Universal configurable blocks - a novel microarchitecture for field programmable 
logic devices (FPL)." The aforesaid invention disclosure described the invention as it was " 
later disclosed and claimed in the above-identified patent application. 

Enclosed herewith, as corroborating evidence, are a letter dated January 22, 1998 signed 
by the inventor Mr. Siemers with an attachment in the form of an invention disclosure 
entitled "Universal configurable blocks • a novel microarchitecture for field programmable 
logic devices (FPL) 1 * which was submitted initially to Siemens AG and subsequently to the 
patent film of Jannig & Repkow, which substantiate thai the undersigned inventor invented - 
and "reduced to practice" the claimed invention of (he instant patent.application at least one 
day prior to September 1 4, 1 998 . 
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Sehr geehrter Hr. Hassa, 

zunachst mochte ich mich einmal bei Ihnen fur Hire Weihnachts- und Neujahrswunsche sehr herzlich 
bedanken, verbunden mit den besten Wiinschen fur Sie in 1998. Zugleich kann ich Ihnen versichern, dafi 
ich mich um die Erhaltung meiner Aktivitaten bemiihen werde. 

AnJaBlich meines letzten Miinchen-Besuchs am 21.01.98 habe ich bei Hm. Platzoder den Vertrag fur 
die beiden Patentvorschlage aus 1997 unterzeichnet, so daB dies nunmehr auch vollstandig gekllrt ist. 
Bei dem anschlieBenden Gespr&ch bei Hrn. Dr. von Wendorff sind wir beide jedoch ubereingekommen, 
daB eine Anmeldung in einem venvandten Gebiet noch dringender ist als in den nunmehr ubertragenen. 

Es handelt sich dabei um eine neue Architektur ftir Feldprogrammierbare Logikbausteine (FPL), die mit 
einem Teil aus dem >S<puter eng verknupft ist. Diese Architektur heiBt UCB (Universal Configurable 
Block) und wird nach unserer gemeinsamen Uberzeugung in naher Zukunft wirklich zum Tragen 
kommen, da diese Plattform gemeinsam fur FPL und Mikrocontroller Verwendung finden kann. 

Ich habe daher die notwendigen Seiten aus dem Gesamtkonzept herausgelost und erganzt und ubersende 
Ihnen hiermit dieses Architekturkonzept zur Priifung, ob dieses fur eine Patentanmeldung Verwendung 
finden konnte. Ich bitte um Entschuldigiuig, daB ich Sie hiermit quasi uberfalle, aber in diesem Fall 
halte ich Eile fur geboten. 

Ich mochte Sie bitten, moglichst umgehend mit mir Kontakt au&unehmen. Sie erreichen mich noch diese 
Woche unter den Rufiiummern 0481/8555-832 (dienstlich), 05121/267775 (Donnerstag und Freitag) 
sowie meiner Funkrufiiummer 0177/298 1003. 

Mit freundlichen GruBen 

Lr. & 
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Prof. Dr. Christian Siemers, Hildesheim: 

Universal Configurable Blocks - 
eine neuartige Mikroarchitektur fur Field Programmable 

Logic Devices (FPL) 

1 Einleitung 

Rekonfigurierbare bzw. strukturierbare Hardware, haufig als Feldprogrammierbare 
Logikbausteine (Field Programmable Logic Devices, FPL) bezeichnet, ist in der Bekanntheit 
deutlich gestiegen: War die strukturierbare Hardware vor einiger Zeit etwas fur Spezialisten, 
die sich mit dem Ersatz von 'fertigen' Bausteinen befafiten und sogenannte Glue Logic bzw. 
State Machines einfacher bis mittlerer Komplexitat darin implementierten, so hat sich die 
Gruppe der Forscher und Entwickler in Richtung Informatik erweitert. Die Grunde fur diesen 
neuerlichen Attraktivit&tsgewinn liegen in der wachsenden GroBe von feldprogrammierbaren 
Bausteinen, die nunmehr zur Implementierung ganzer Systeme bzw. Algorithmen in Hardware 
geeignet sind, bei gleichzeitig sinkenden Preisen. 

Damit hat sich auch der Charakter von Hardware- Applikationen deutlich gewandelt. 
Rekonfigurierbare Hardware ist sehr schnell, im Vergleich zur Software ahnlich 
programmierbar, wenn auch im Detail deutliche Unterschiede bestehen. Es ist jedoch das 
Denken in ganzen Algorithmen bzw. in wesentlichen Kernteilen, das die Einbettung von FPLs 
in ein Rechnersystem nunmehr beeinfluBt. Um hier einige Beispiele zu nennen: DSP- 
Algorithmen, sehr schnelle Steuerungssysteme, Hardware-Beschleuniger [6]. Die Integration 
von Prozessoren und FPL wird im allgemeinen als ein sehr wesentlicher Teil des Hardware/ 
Software Co-Designs [1][6] angesehen. 

Mit diesem hier beschriebenen Ansatz wird nunmehr eine FPL-ArGhitektur vorgestellt, die sich 
aufgrund ihrer Struktur wesentlich besser in ein Mikroprozessor/-controllersystem integrieren 
laBt, da sich der Ablauf von 'Software' im Prozessor und im FPL auf eine gemeinsame Basis 
stellen laBt. Hierzu muB naturlich der Begriflf der Software naher beschrieben und 
eingeschrankt werden. Software fur einen Mikroprozessor/Mikrocontroller besteht auf der 
untersten Ebene aus Instruktionen, die gemaB dem vbn-Neumann-Modell sequentiell geladen 
und abgearbeitet werden. Dies wird fiir superskalare Prozessoren, die eine nebenlaufige 
Ausfuhrung gestatten, dahingehend variiert, daB die Ergebnisse denen eines sequentiellen 
Ablaufs entsprechen (Ergebnissequentialitat). 

Diese Form der Software auf unterster Ebene wird zumeist von optimierenden Compilern, 
seltener durch eine direkte Assemblerprogrammierung erzeugt Ein sequentieller FluB von 
Instruktionen bewirkt Aktionen in einer dafur geeigneten Ablaufeinheit, in der Regel ein 
Prozessor, so daB man dies als KontrollfluB-dominiert bzw. prozedural (control flow 
procedural) bezeichnet. Im Unterschied hierzu werden FPLs in ihren Strukturen konfiguriert, 
diese strukturale Programmierung steuert einen DatenfluB. Ziel dieses Papers ist es, eine FPL- 
Struktur zu definieren, die mit Hilfe des bereits fiir den >S<puter [2] angegebenen Algorithmus 
zur Umsetzung von sequentiellen Instruktionen in strukturale Informationen programmiert 
werden kann und somit in der Lage ist, diesen sequentiellen Instruktionsstrom ohne weitere 
Steuereinheiten auszufuhren. 
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Diese Form der Programmierung wird als struktur-prozedurale Programmierung (Procedural 
Driven Structural Programming, PDSP) bezeichnet. 

Die in diesem Paper vorgeschlagene neue Architektur fur Feldprogrammierbare Bausteine kann 
demnach zugleich als eine Stand-Alone-Einheit betrachtet werden, die durch eine zumeist 
kurze Sequenz von Instruktionen programmiert wird und dieses Programm selbstandig 
ausfiihrt, sie kann gleichzeitg als Ausfuhrungseinheit in Prozessoren Verwendung finden. Dies 
steht in engem Zusammenhang mit dem >S<puter-Konzept [2][3][4], bei dent diese 
Architektur in nur leicht variierter Form bereits Einzug gehalten hat. Die neuartige FPL- 
Architektur, mit Universal Configurable Block (UCB) bezeichnet, wird insbesondere fur 
Systeme vorgeschlagen, die im Rahmen eines Hardware/Software Co-Designs zusammen mit 
Prozessoren Teile der Gesamtapplikation in sich aufhehmen sollen. 

2 Universal Configurable Blocks (UCB) 

Die in [2] [3] [4] eingefuhrten Functional Units innerhalb des >S<puters wurden zur Anpassung 
einer Struktur an einen sequentiellen InstruktionsfluB genutzt - quasi als Speichermedium fur 
eine Makroinstruktion, die einem Hyperblock entspricht. Diese Sichtweise wird durch die 
Angabe eines Algorithmus fiir eine Umrechnung des Instruktionsflusses in die Struktur 
unterstutzt. 

Die Functional Units lassen sich jedoch aus dem Kontext der s-Unit herauslosen und gesondert 
betrachten. Dies erfolgt hier mit Hinblick auf die Allgemeingultigkeit der nachfolgenden 
Uberlegungen. Eine derartige Struktur, wie sie in den Functional Units vorhanden ist, kann als 
neue Struktur fiir feldprogrammierbare Bausteine betrachtet werden. Der Algorithmus zur 
Bestimmung der Struktur aus den Instruktionen schaffi dann ein Interface zwischen der- 
Software und der Struktur, das auch im Rahmen des Hardware/Software Co-Design sehr 
wichtig ist. 

Zunachst werden jedoch die Functional Units zu den eigenstandigen Universal Configurable 
Blocks (UCBs) erweitert. 

2.1 Die Definition der Zielhardware: Universal Configurable Block 

Der grundlegende Aufbau der Zielhardware wurde bereits als Functional Unit innerhalb der 
>S<puter- Architektur vorgestellt ([2] [3] [4]). Hierzu wurde die ALU-Struktur in kleinere 
Einheiten, die mit AUs und CoUs (Arithmetic Units, Compare Units) bezeichnet wurden, 
aufgeldst und durch ein Netzwerk konfigurierbarer Multiplexer und Demultiplexer miteinander 
verbunden. Abb. 2-1 zeigt das Aufbauprinzip, die im Rahmen dieses Kapitels nunmehr zu 
Universal Configurable Blocks (UCB) erweitert werden. 
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Abb. 2-1: Prinzipstruktur der UCBs 



Ein derartiger UCB besteht demnach aus einem Registerblock als dem synchronisierenden Teil 
und einem konfigurierbaren, asynchronen Schaltnetz zwischen den Aus- und Eingangen des 
Registerblocks. Schreibzugriffe im Registerblock sind grunds&tzlich getaktet. Der UCB 
entspricht in seinem Aufbau einer urn die Taktgenerierung und die Generierung des Ready- 
Signals erweiterten Functional Unit mit folgenden, asynchron miteinander gekoppelten 
Bestandteilen: 

• Arithmetic Unit (AU, Type A) 

• Compare Unit (CoU, Type B) 

• Multiplexer (Mul_C, Type C) 

• Multiplexer (Mul_D, Type D) 

• Demultiplexer (Demul, Type E) 

• Compare Unit (CoU2, Type F): Diese gegenuber der in [2][3][4] vorgestellten Functional 
Unit neue Teileinheit kann das Ready-Signal fur eine steuernde Einheit generieren. Hierzu 
werden wie fiir Typ B die Quellen per Multiplexer ausgewahlt, zusatzlich kann man 
FALSE (Standardeinstellung) oder TRUE auswahlen, um einen einzigen bzw. einen 
dauernden Durchlauf des Hyperblocks zu ermdglichen. Die Auswahl eines berechneten 
Ausgangssignals dieser Compare Unit hingegen ermoglicht die einfache Integration eines 
Schleifenzahlers in Hardware. Die CoU2 wird im wesentlichen aufgebaut sein wie die 
CoUs (Type B). Die singulare Verwendung fur die Loop-Behandlung garantiert die 
Verfiigbarkeit fur ein explizites Schleifenende. 

CoU2-Teileinheiten kdnnen mehrfach in dem UCB vorhanden sein und einem erweiterten 
Interface zur Auflenwelt dienen. Dies bedeutet, daB UCBs eigenst&ndig mit anderer 
Hardware, beispielsweise Peripherieeinheiten in einem Mikrocontroller oder anderen 
UCBs interagieren konnen. 

• Die Clock Generation Unit (CGU) erzeugt einen Takt fiir die Ubemahme von Ergebnissen 
in Register. Sie koppelt im einfachsten Fall einen Mastertakt mit dem Enable-Signal einer 
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vorgeschalteten Einheit, beispielsweise eines Dispatchers oder eines Interface zum 
Speicher oder zu peripheren I/O Komponenten etwa via Load/Store-Pipeline. 

Das Neuartige der UCBs als FPL- Architektur besteht also in folgenden Merkmalen: 

• Die datenverkniipfenden Einheiten integrieren h8here Komplexit&ten verglichen mit 
bisherigen FPL-Architekturen. Dies bedeutet die zumindestens partielle Abkehr von DNF- 
(Disjunktive Normalform) oder Look-Up-Table basierten, logischen Verknpufungen hin 
zu arithmetisch-Iogischen Verknupfiingen, von denen jeweils eine, ggf mehrere 
konfigurierbare in einer Arithmetical Unit (AU) vorhanden ist. 

• Einhergehend mit dem vorgenannten Punkt ist die Blockung in den UCBs grober als in 
den FPGAs (Field Programmable Gate Arrays), d.h. die Grofle eines Blocks, der 
insgesamt fur eine Makrooperation programmiert werden kann, ist groBer und 
vergleichbar eher mit der von CPLDs (Complex Programmable Logic Devices); Dies 
bedeutet eine etwas geringere Flexibilit&t in der Anpassung der wirklich genutzten 
Ressourcen an die Anforderung, ergibt andererseits jedoch eine optimale Anpassung an 
Algorithmen, die in Mikrocontrollern ablaufen. 

• Die Kopplung an Speicher und Input/Output-Elemente erfolgt Qber Load/Store-Pipelines 
sowie die Clock Generation Unit, um hier eine moglichst groBe Flexibilitat zu erreichen. In 
handelsiiblichen FPLs ist dies in sogenannten IO-Blocken ohne grdBere eigenstandige 
Funktionalitat integriert, so daB ein AuBenzugrifF durch die strukturale Hardware intern 
gesteuert werden muB. 

• Die Registerarchitektur ist besonders hervorzuheben, da die Register das 
synchronisierende Element innerhalb darstellen und zugleich mit der AuBenwelt 
kommunizieren. Verknupfiingen zwischen zwei Register erfolgen der Architektur 
entsprechend asynchron. 

2.2 Die UCB- Architektur im VerhSltnis zur Prozessorarchitektur 

Die Architektur des UCBs ist derart gewahlt, daB fiinf Gruppen von Instruktionen, wie sie in 
dem Befehlsstrom eines (superskalaren) Prozessors vorkommen, hierin ausfuhrbar sind: 

1 . Unkonditionierte Befehle zur Bearbeitung von Daten einschlieBlich einer Datenkopie 
zwischen Registern: Diese Befehlsgruppe, im folgenden als 'normale Befehle' bezeichnet, 
beinhaltet arithmetische und logische Verknupfung zwischen Daten zu neuen Werten 
sowie die Move-Befehle zur Kopie von Registerinhalten. Allgemeines Format dieser 
Befehle lautet 

<mnemonic> destination reg>, <source reg. 1>, <source reg. 2> 

2. Konditionierte Befehle zur Bearbeitung von Daten bei Vorliegen einer Kondition: Diese 
Befehlsgruppe, im folgenden als 'bedingte Befehle' bezeichnet, beinhaltet grundsatzlich die 
gleichen Befehle wie unter 1 . genannt, wobei in einer konkreten Realisierung naturlich 
nicht alle Verknupfiingen implementiert seien mussen. Das allgemeine Format lautet 

<mnemonic>p <destination reg.>, <source reg. 1>, <source reg. 2> <p-flag>, 

wobei durch das *p' am Ende des Mnemonic die Abh&ngigkeit von der Bedingung 
('predicated instructions') und durch das p-flag die Bedingung formuliert wird. Es wird 
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grundsatzlich angenommen, daO die Bedingung in Form eines Flags, bei Erweiterung des 
Mod el Is auch durch logische Kombination mehrerer Flags definierbar ist. 

3. Die Predicate-Befehle zur Bestimmung des Werts eines Bedingunsflags: Dtese 
Befehlsgruppe, im folgenden durch 'pxx-Befehle' abgekiirzt, bestimmt den Wert eines 
Bedingungsflags zur Laufzeit durch einen Vergleich, bei dem xx durch die Abkurzungen 
gt (Greater Than), ge (Greater than or Equal), eq (EQual), ne (Not Equal), le (Less than 
or Equal) und It (Less Than) ersetzt wird, wobei andere Vergleiche ebenfalls integrierbar 
sind. Befehle dieser Gruppe besitzen somit das Format 

<mnemonic> <source reg. 1>, <source reg. 2>, <p-flag> . 

Sie sind mit den ublichen Branch-Befehlen vergleichbar und dienen deren Ersatz durch 
Anwendung der Mf-conversion' [5], 

4. Die Loop-Befehle zur Schleifenwiederholung am Ende eines Hyperblocks: Diese Befehle, 
im Format 

loopxx <source reg. 1>, <source reg. 2> 

mit xx als Abkurzung der ublichen Vergleiche (ne, eq ...) codiert, fiihren die Verzweigung 
an den Anfang eines Hyperblocks durch, falls die Bedingungen wahr ist. Dementsprechend 
soil das Ready-Signal generiert werden, wenn die Schleifenbedingung nicht mehr erfixllt 
ist. 

5. Die Intxx-Befehle zur Erzeugung von Signalen an die AuBenwelt des UCBs: Diese 
Befehle, im Format 

intxx <source reg. 1>, <source reg. 2>, <int_signal> 

mit xx als Abkurzung der ublichen Vergleiche (ne, eq ...) einschlieBlich TRUE und 
FALSE, erzeugen im ProgrammfluB ein ruckgefiihrtes Signal zum Interface des UCBs, 
falls die Bedingung wahr ist. Dieses Signal, in int_signal angegeben, kann zur 
Kommunikation mit anderen Einheiten genutzt werden. Intxx-Befehle stellen eine 
Verallgemeinerung der loopxx-Befehle dar, indem nicht nur das ausgezeichnete Ready- 
Signal, sondem allgemeine Hardwaresignalleitungen gesetzt werden. 

Ein UCB soli optimal so dimensioniert sein, daB er im allgemeinen einen Hyperblock in sich 
zur Ausfuhrung aufhehmen kann. Hierzu wird fur die weitere Ausfuhrung ohne Beschrankung 
angenommen, daB die Busse zwischen den Multiplexern und den zu verbindenden Teilblocken 
in den gewunschten Dimensionierungen vorhanden sind und durch einfache Konfigurierungs- 
bits schaltbar sind. FQr die nachfolgende Formulierung des Konfigurierungsalgorithmus' wird 
zusatzlich ein vollstandiges Netzwerk angenommen, wobei sich hier bei der Beschrankung auf 
Teilnetze Einschrankungen fur den nachfolgenden Algorithmus ergeben wurden. 

2.3 Ein Beispiel zur Integration in die UCB-Architektur 

AbschlieBend zu den bisherigen Betrachtungen soil ein Beispiel aus dem I/O-Bereich 
dargesteUt werden. Timer-gesteuert wird ein AD-Wandler, dessen Wandlungsbreite mit 8 Bit 
angenommen wird, gestartet und der Wert mit einer 12-Bit-Zahlmarke zusammen gespeichert. 
Der AD-Wert wird dann auf Uber- und Unterschreitung spezifizierter Grenzen uberwacht, 
wobei dann in eine weitere Routine verzweigt wird. Die Routine bricht nach 2048 Messungen 
ab. 



Prof. Dr. Christian Siemers 
Universal Configurable Blocks (UCB) 



Seite5 



Diese Anwendung erzeugt bei einer reinen Softwarelosung einige Probleme: Da ein typischer 
AD-Wandler, der in einem Mikrocontroller integriert ist, nicht spontan das Ergebnis liefert, 
also als Flashwandler arbeitet, sondem eine Wandlungszeit im Bereich einiger Mikrosekunden 
besitzt, muB bei exakter Ausfiihrung der Anwendungsspezifikation einer der folgenden Wege 
bestritten werden: 

• Der Timer l6st einen Interrupt aus, innerhalb dessen Serviceroutine die Wandlung 
gestartet wird. Die Timerserviceroutine wird beendet, der AD-Wandler lost bei 
Beendigung der Wandlung ebenfalls einen Interrupt Request aus. In der nunmehr 
folgenden zweiten Serviceroutine wird der AD- Wert ausgelesen und verarbeitet. 

• Der Timer lost einen Interrupt aus, innerhalb dessen Serviceroutine sowohl die Wandlung 
gestartet, auf das Wandlungsende gewartet und die Wandlungswerte verarbeitet werden. 

Die 2. Variante bietet sich bei im Vergleich zu Interruptlatenzzeiten kurzen Wandlungszeiten 
an, ansonsten ware die erste Variante zu bevorzugen, da hier viel Wartezeit gespart wird. In 
der Praxis existiert jedoch ein dritter Weg, der im Prinzip nicht exakt den Vorgaben entspricht, 
jedoch im allgemeinen zulassig ist: Die Wandlung selbst wird in die Lesepausen verlegt. Der zu 
einem Timer-Interruptzeitpunkt gelesene Wert entspricht dann der Wandlung der 
vorhergehenden Periode, nach dem Lesen wird eine neue Wandlung fur die nachste Periode 
gestartet. Im wesentlichen ist bei diesem Verfahren die Zeitverschiebung und die Ungiiltigkeit 
des ersten Werts zu beachten. 

Fur einen iiblichen Mikrocontroller wird normalerweise das in der Praxis relevante Verfahren 
einer Intemipt-gesteuerten Routine realisiert, die die Wandlung in die Lesepausen verlegt. Die 
ersten Varianten wiirden zu einem erheblich gesteigertem Zeitbedarf fuhren. Es wird weiterhin 
angenommen, daB die Abfrage und die Verarbeitung in der Serviceroutine des Timerinterrupts 
erfolgen. 



int *p_adc, adc_value, upper_limit, lower_limit, adc — ready; 
int adc_array [ 4096] ; 

void ha rdware_thread readADCC) 
{ 



int 
whi 
{ 



x = 0; 
le( x < 4096 ) 

if{ adc_ready 



1 ) 



adc_value = *p_adc; . 

if( adc_value > upper_limit 

out_of_ range ( ) ; 
adc_array [x++] ~ x; 
adc_array[x++] *» adc_value; 



// Access to AD converter 

I | adc_value < lower_limit ) 

// call to exception routine 

// index information 

// and adc value are stored 



Abb. 2-2: C-Sourcecode far ADC-Programm 

Die Vermutung liegt nun nahe, daB fur derartige Applikationsteile UCBs ebenfalls zur 
Unterstiitzung von peripheren Controllerelementen dienen kdnnen. Die Programmierung des 
UCB kann sowohl in strukturaler als auch in sequentieller Weise entsprechend in einer 
(Software-)Hochsprache erfolgen - einen vorhandenen Compiler vorausgesetzt, der die PDSP- 
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Ubersetzung beherrscht. Abb. 2-2 gibt den Algorithmic zur Aufhahme von 2048 AD-Werten, 
Speicherung des jweiligen Wertes mit zusatzlicher Indexinformation und Vergleich auf Uber- 
bzw. Unterschreitung von Grenzen in C an: 

Ein fur die UCB-Architektur optimierender Compiler konnte diesen Sourcecode unter 
Berucksichtigung der neuen Instruktionen in folgenden Assemblercode ttbersetzen: 



mov 


rl, 


p_adc 


• address of ADC 


mov 


r4, 


0 


• variable x 


mov 


r5, 


1 


• variable x+1 


mov 


r6. 


adc_ array 


■ address of array 


Id 


r2. 


upper_limit ; 


Id 


r3, 


lower_limit ; 


LO: Id 


rO, 


(rl) ; AD value is loaded 


intgt 


rO, 


r2, il 


■ and compared for int 


intlt 


rO, 


r3, i2 


* generation 


St 


(r6+r4>, r4 


• the storage 


St 


<r6+r5), rO 




add 


r4, 


r4, 2 




add 


r5, 


r5, 2 




looplt 


r4, 


4096, LI 





Register contents: 


rO 


AD value 


rl 


&ADC 


i2 


upper limit 


r3 


lowcrlimit 


r4 


X 


r5 


x+1 


r6 


&adc arrav 



Abb. 2-3: Generierung des Assemblercode durch optimierenden Compiler 

Die dargestellte Generierung wurde unter yerschiedenen Annahmen durchgefuhrt, die im 
einzelnen erlautert werden mussen. Zunachst fehlt die im C-Code angegebene Bedingung, daB 
die Schleife nur beim Vorliegen des ADC_READY-Signals durchlaufen werden darf, im 
Assemblercode vollstandig. Es wird hierzu angenommen, daB die Bedingung, die quasi eine 
Triggerung darstellt, vom Compiler in ein Enable-Signal fur den Takt umgesetzt werden kann 
(siehe hierzu auch Abb. 2-1). Dieses Enable-Signal steuert den Ubernahmetakt fur den UCB 
und entspricht damit einem Trigger. 1st diese Annahme unzulassig, dann mussen alle Befehle 
von dem Signal ADC_READY abhangig gemacht werden, was prinzipiell mdglich ist, jedoch 
sehr viele Vergleichsressourcen kostet. 

Zudem sind bedingte Interruptaufrufe (intxx) in dem Assemblercode vorhanden, die in einem 
UCB auf die Signalgenerierung abgebildet werden konnen. Diese Signalgenerierung an eine 
vorgelagerte Stufe muB dort zwischengespeichert und verarbeitet werden, etwa durch einen 
Interniptaufruf an den eigentlichen Prozessor. 

Unter diesen Voraussetzungen entsteht folgende Struktur in einem UCB: 
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Abb. 2-4: Abbildung ADC-Routine in UCB 

Dieses Beispiel zeigt die grundsatzliche Ubertragbarkeit von Routinen fur intelligente 
Peripherie in das Konzept der UCBs, wobei insbesondere fur die Verwendbarkeit von 
prozeduralen Compilern einige Voraussetzungen gemacht werden muflten. Insbesondere mufi 
der Systementwickler die Teile, die jeweils in einem UCB laufen sollen, als eigenstandige 
Threads deklarieren (im C-Beispiel mit Hilfe des neuen Schliisselwortes hardware_thread), 
wahrend der Compiler selbst gefordert ist, dies fur einen UCB zu iibersetzen. 



2.4 Zusammenfassung 

Ziel dieses Konzepts war die Einfuhrung einer neuen Architektur fur feldprogrammierbare 
Logik, die zugleich in Mikrocontrollern bzw. -prozessoren integriert sein kann und mit Hilfe 
des bereits angegebenen PDSP- Algorithmus' (Procedural Driven Structural Programming) 
durch einen sequentiellen Instrtiktionsstrom ladbar ist. Diese Architektur zeichnet sich durch 
die Einfiihrung einer neustrukturierten Hardware aus, die auf den Anwendungskreis optimiert 
ist. 

Beispielhaft konnte hierbei gezeigt werden, in welcher Form die UCBs programmiert und 
betrieben werden konnen. Diese Struktur ist in der Lage, sowohl stand-alone als auch in 
Zusammenarbeit mit Mikrocontrollern betrieben werden zu konnen und zeigt durch die enge 
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Anpassung an die Architektur und Arbeitsweise von Prozessoren insbesondere im Rahmen 
eines Co-Designs sehr gute Ergebnisse. 



3 Literatur 

[1] De Micheli, G. ; Gupta, R., „Hardware/Software Co-Design", Invited Paper in: Proceedings of the IEEE 
Vol. 85(3), Special Issue on Hardware/Software Co-Design, 341 365, March 1997. 

[2] Siemers, C: Prozessor mit Pipelining-Aufbau. Anmeldung am 21.08.1996 unter der Nummer 196-34 
031.4 beim Deutschen Patentamt 

[3] Siemers, C; Mailer, D.P.F., „Der >S<puter: Ein dynamisch rekonfigurierbares Mikroarchitekturmodeil 
zur Erreichung des maximalen Instruktionsparallelitatsgrades", Vortragsband der 14. ITG/GI-Fachtagung 
Architektur von Rechensystemen ARCS '97, Rostock, September 1997, S. 133 142, VDE Verlag, Berlin 
und Offenbach, 1997 

[4] Siemers, C; Mailer, D.P.F., „The >S<puter: A Novel Microarchitecturemodel for the Execution of 
Instructions inside Processors", in: Xu De, K.-E. Groflpietsch, Ch. Steigner (Eds.): Proceedings of the 
Second Sino-German Workshop on Advanced Parallel Processing Technologies APPT *97, Koblenz, 
September 1997, p. 75 82. Ffllbach Verlag, Koblenz, 1997. 

[4] Smith, James E.; Sohi, Gurindar S., „The Microarchitecture of Superscalar Processors", invited Paper in 
Proceedings of the IEEE, Special Issue on Microprocessors, Vol. 83 (12), p. 1609 1624, 1995. 

[5] Wen-Mei W. Hwu et. al., „Compiler Technology for Future Microprocessors", Invited Paper in 
Proceedings of the IEEE Vol. 83 (12) , Special Issue on Microprocessors, 1625 1640, Dec. 1995. 

[6] R.W. Hartenstein, J. Becker, R. Kress, „Custom Computing Machines vs. Hardware/Software Co-Design: 
From a Globalized Point of View", 6th Int. Workshop on Field Programmable Logic andAppl., FPL '96, 
Darmstadt, Sept. 1996, Lecture Notes in Computer Science 1142, Springer 1996. 



Prof. Dr. Christian Siemers 
Universal Configurable Blocks (UCB) 



Seite9 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



Ul LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




Docket No. : GR 989 P 8 1 1 0 
Application No. 09/816,933 




CERTIFICATION 



below named translator, hereby declare that: my name and post office 
address are as stated below; that I am knowledgeable in the English and German 
languages, and that I believe that the attached text is a true and complete 
translation of a letter from Dr. Christian Siemers, dated January 22, 1998 to Mr. 
Hassa, including an invention disclosure (pages 2-12). 

I hereby declare that all statements made herein of my own knowledge are true and 
that all statements made on information and belief are believed to be true; and 
further that these statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, 
under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued 
thereon. 



November 30, 2005 

Lerner & Greenberg, P.A. 
P.O. Box 2480 
Hollywood, FL 33022-2480 
Tel.: (954)925-1100 
Fax.: (954)925-1101 




Letter from Dr. Christian Siemers, Hildesheim, to Siemens AG, Munich, 
January 22, 1998 



Follow-up patent application 
Dear Mr. Hassa 

Firstly I would like to thank you sincerely for your Christmas and New Year wishes, coupled 
with my best wishes for you in 1998. At the same time I can assure you that I will endeavor to 
maintain my activities. 

During my last visit to Munich on January 21, 1998, with Mr. Platzoder I signed the contract 
for the two patent proposals from 1997, and so this is now also completely clarified. In the 
subsequent conversation with Dr. von Wendorff, however, we both agreed that an application 
in a related field is even more urgent than in those now transferred. 

This concerns a new architecture for field programmable logic devices (FPL), which is 
closely linked with part of the >S<puter. This architecture is called UCB (Universal 
Configurable Block) and we are both convinced that it will really come to fruition in the near 
future since this platform can be used jointly for FPL and microcontrollers. 

I have therefore taken the necessary pages from the overall concept and supplemented them 
and I am hereby sending you this architecture concept for you to examine whether this could 
be used for a patent application. Forgive me for virtually bombarding you with this, but I 
consider haste to be imperative in this case. 

Please would you contact me as soon as possible. You can still reach me this week under the 
telephone numbers 0481/8555-832 (office), 05121/267775 (Thursday and Friday) and my 
pager number 0 1 77/298 1 003 . 
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Prof. Christian Siemers, Hildesheim: 

Universal configurable blocks - 
a novel microarchitecture for field programmable 
logic devices (FPL) 

1 Introduction 

Awareness of reconfigurable or structurable hardware, often referred to as field 
programmable logic devices (FPL), has increased significantly among those working in the 
field: whereas a while ago structurable hardware was something for specialists who were 
concerned with the replacement of "finished" devices and implemented so-called glue logic 
or state machines of simple to medium complexity therein, the group of researchers and 
developers has expanded in the direction of information technology. The reasons for this 
recent gain in attractiveness can be found in the increasing size of field programmable 
devices, which are now suitable for implementing whole systems or algorithms in hardware, 
in conjunction with falling prices. 

The character of hardware applications has thus also changed significantly. Reconfigurable 
hardware can be programmed very fast, similarly to software, even though there are 
significant differences in details. However, it is the thinking in whole algorithms or in 
essential core parts which now influences the embedding of FPLs in a computer system. To 
mention a few examples here: DSP algorithms, very fast control systems, hardware 
accelerators [6]. The integration of processors and FPL is generally regarded as a very 
important part of hardware/software co-design [1][6]. 

This approach described here now presents an FPL architecture which, on account of its 
structure, can be integrated significantly better into a microprocessor/microcontroller system, 
since the sequence of "software" in the processor and in the FPL can be set to a common 
basis. For this purpose, it is necessary, of course, for the term software to be more closely 
described and qualified. Software for a microprocessor/microcontroller consists at the lowest 
level of instructions which are sequentially loaded and processed in accordance with the 
von Neumann model. This is varied for superscalar processors, which permit concurrent 
execution, to the effect that the results correspond to those of a sequential sequence (result 
sequentiality). 

This form of software at the lowest level is usually generated by optimizing compilers, less 
often by direct assembler programming. A sequential flow of instructions brings about actions 
in a sequence unit suitable therefor, generally a processor, and so this is referred to as control 
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flow dominated or control flow procedural In contrast thereto, the structures of FPLs are 
configured and this structural programming controls a data flow. It is an aim of this paper to 
define an FPL structure which can be programmed with the aid of the algorithm already 
specified for the >S<puter [2] for converting sequential instructions into structural 
information and is thus able to execute this sequential instruction stream without further 
control units. 

This form of programming is referred to as procedural driven structural programming 
(PDSP). 

The new architecture for field programmable devices which is proposed in this paper may 
accordingly at the same time be regarded as a standalone unit which is programmed by means 
of a usually short sequence of instructions and executes this program independently; it may 
simultaneously be used as an execution unit in processors. This is closely related to the 
>S<puter concept [2] [3] [4], in which this architecture in just a slightly varied form has 
already made an inroad. The novel FPL architecture, designated by universal configurable 
block (UCB), is proposed in particular for systems which, in the context of a 
hardware/software co-design, together with processors are intended to incorporate parts of the 
overall application in themselves. 

2. Universal configurable blocks (UCB) 

The functional units within the >S<puter that were introduced in [2] [3] [4] were used for 
adapting a structure to a sequential instruction flow; virtually as a storage medium for a 
macroinstruction corresponding to a hyperblock. This aspect is supported by the specification 
of an algorithm for converting the instruction flow into the structure. 

However, the functional units can be detached from the context of the s-unit and be 
considered separately. This is done here with regard to the general validity of the 
considerations that follow. A structure of this type such as is present in the functional units 
can be regarded as a new structure for field programmable devices. The algorithm for 
determining the structure from the instructions then creates an interface between the software 
and the structure, which is also very important in the context of the hardware/software 
co-design. 

Firstly, however, the functional units are extended to form the independent universal 
configurable blocks (UCBs). 
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2.1 Definition of the target hardware: universal configurable block 

The fundamental construction of the target hardware has already been presented as a 
functional unit within the >S<puter architecture ([2][3][4]). For this purpose, the ALU 
structure was resolved into smaller units, designated by AUs and CoUs (arithmetic units, 
compare units), and connected to one another by a network of configurable multiplexers and 
demultiplexers. Fig. 2-1 shows the construction principle, which will now be extended to 
form universal configurable blocks (UCB) in the context of this chapter. 
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Fig. 2-1: Basic structure of the UCBs 



A UCB of this type accordingly comprises a register block as the synchronizing part and a 
configurable, asynchronous switching network between the outputs and inputs of the register 
block. Write accesses in the register block are clocked, in principle. In terms of its 
construction, the UCB corresponds to a functional unit extended by the clock generation and 
the generation of the ready signal, with the following component parts that are 
asynchronously coupled to one another: 



• Arithmetic Unit (AU, Type A) 



• Compare Unit (CoU, Type B) 

• Multiplexer (Mul_C, Type C) 

• Multiplexer (Mul_D, Type D) 



• Demultiplexer (Demul, Type E) 
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• Compare Unit (CoU2, Type F): This subunit, which is new in comparison with the 
functional unit presented in [2][3][4], can generate the ready signal for a controlling unit. 
For this purpose, as for Type B, the sources are selected by multiplexer; in addition, it is 
possible to select FALSE (standard setting) or TRUE in order to enable a single or a 
continuous pass of the hyperblock. The selection of a calculated output signal of this 
compare unit, by contrast, enables the simple integration of a loop counter in hardware. 
The CoU2 will essentially be constructed like the CoUs (Type B). The singular use for 
the loop treatment guarantees the availability for an explicit loop end. 

CoU2 subunits may be present multiply in the UCB and are used for an extended 
interface to the outside world. This means that UCBs can interact independently with 
other hardware, for example peripheral units in a microcontroller, or other UCBs. 

• The clock generation unit (CGU) generates a clock for the acceptance of results in 
registers. In the simplest case, it couples a master clock to the enable signal of a unit 
connected upstream, for example of a dispatcher or an interface to the memory or to 
peripheral I/O components, for instance via load/store pipeline. 

The novelty of the UCBs as FPL architecture thus consists in the following features: 

• The data-combining units integrate higher complexities compared with previous FPL 
architectures. This means at least partially turning away from DNF (disjoint normal form) 
or look-up table based logic combinations toward arithmetic-logic combinations, of 
which there is in each case one configurable combination, if appropriate a plurality of 
configurable combinations, present in an arithmetical unit (AU). 

• In association with the aforementioned point, the blocking in the UCBs is coarser than in 
the FPGAs (field programmable gate arrays), that is to say that the size of a block which 
can be programmed overall for a macro operation is larger and comparable rather with 
that of CPLDs (complex programmable logic devices). This means a somewhat lower 
degree of flexibility in the adaptation of the resources actually used to the requirement, 
but on the other hand produces an optimal adaptation to algorithms executed in 
microcontrollers. 

• The coupling to memory and input/output elements is effected via load/store pipelines 
and also the clock generation unit, in order to achieve a maximum flexibility here. In 
commercially available FPLs, this is integrated in so-called IO blocks without a relatively 
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high degree of independent functionality, so that an external access has to be controlled 
internally by the structural hardware. 

• The register architecture is to be particularly emphasized since the registers represent the 
synchronizing element within and at the same time communicate with the outside world. 
Combinations between two registers are effected asynchronously in accordance with the 
architecture. 

2.2 The UCB architecture in relation to the processor architecture 

The architecture of the UCB is chosen in such a way that five groups of instructions such as 
occur in the instruction stream of a (superscalar) processor can be executed therein: 

1. Unconditioned instructions for processing data including a data copy between registers: 
This group of instructions referred to hereinafter as "normal instructions", comprises 
arithmetical and logic combination between data to form new values and also the move 
instructions for copying register contents. The general format of these instructions reads 

<mnemonic> destination reg.>, <source reg. 1>, <source reg. 2> 

2. Conditioned instructions for processing data when a condition is present: This group of 
instructions, referred to hereinafter as "conditional instructions", in principle comprises 
the same instructions as mentioned under 1., in which case, of course, not all 
combinations have to be implemented in a concrete realization. The general format reads 

<mnemonic>p destination reg.>, <source reg. 1>, <source reg. 2> <p-flag>, 

the dependence on the condition ("predicated instructions") being formulated by the "p" 
at the end of the mnemonic and the condition being formulated by the p-flag. It is 
assumed in principle that the condition can be defined in the form of one flag, and in the 
case of the model being extended also by logic combination of a plurality of flags. 

3. The predicate instructions for determining the value of a condition flag: This group of 
instructions, abbreviated hereinafter to "pxx instructions", determines the value of a 
condition flag at the execution time by a comparison where xx is replaced by the 
abbreviations gt (greater than), ge (greater than or equal), eq (equal), ne (not equal), le 
(less than or equal) and It (less than), other comparisons likewise being able to be 
integrated. Instructions of this group thus have the format 
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<mnemoniO <source reg. 1>, <source reg. 2>, <p-flag>. 

They are comparable with the customary branch instructions and serve to replace the 
latter by application of the "if-conversion" [5], 

4. The loop instructions for loop repetition at the end of a hyperblock: These instructions, in 
the format 

loopxx <source reg. 1>, <source reg. 2> 

coded by xx as an abbreviation of the customary comparisons (ne, eq ...), perform the 
branching at the start of a hyperblock if the condition is true. Accordingly, the ready 
signal is to be generated if the loop condition is no longer fulfilled. 

5. The intxx instructions for generating signals to the outside world with respect to the 
UCB: These instructions, in the format 

intxx <source reg. 1>, <source reg. 2>, <int_signal> 

with xx as an abbreviation of the customary comparisons (ne, eq ...) including TRUE and 
FALSE, generate in the program flow a fed-back signal to the interface of the UCB if the 
condition is true. This signal, specified in int_signal, can be used for communication with 
other units. Intxx instructions constitute a generalization of the loopxx instructions in that 
not only the distinguished ready signal but general hardware signal lines are set. 

A UCB is to be optimally dimensioned such that it can generally incorporate a hyperblock in 
itself for execution. For this purpose, it is assumed for the further explanation without 
restriction that the buses are present between the multiplexers and the sub-blocks to be 
connected in the desired dimensionings and can be switched by simple configuration bits. A 
complete network is additionally assumed for the subsequent formulation of the configuration 
algorithm; restriction to sub-networks would in this case result in limitations for the 
subsequent algorithm. 

23 An example of integration into the UCB architecture 

An example from the I/O area will be illustrated to conclude the previous considerations. 
Under the control of a timer, an AD converter, the conversion width of which is assumed to 
be 8 bits, is started and the value is stored together with a 12-bit counting mark. The AD 
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value is then monitored with regard to exceeding and undershooting specified limits, the 
system then branching to a further routine. The routine terminates after 2048 measurements. 

In the case of a pure software solution, this application generates a few problems: Since a 
typical AD converter integrated in a microcontroller does not supply the result spontaneously, 
that is to say operate as a flash converter, but rather has a conversion time in the region of a 
few microseconds, one of the following paths has to be taken for exact execution of the 
application specification: 

• The timer triggers an interrupt, within the service routine of which the conversion is 
started. The timer service routine is ended; the AD converter likewise triggers an 
interrupt request at the end of the conversion. In the second service routine which then 
follows, the AD value is read out and processed. 

• The timer triggers an interrupt, within the service routine of which the conversion is 
started, the end of conversion is awaited and also the conversion values are processed. 

The 2 nd variant is appropriate in the case of short conversion times in comparison with 
interrupt latencies; otherwise, the first variant would be preferable since much waiting time is 
saved in this case. A third path exists in practice, however, which in principle does not 
correspond exactly to the stipulations but is generally permissible: The conversion itself is 
moved into the read pauses. The value read at a timer interrupt instant then corresponds to the 
conversion of the preceding period and a new conversion for the next period is started after 
reading. In the case of this method, it is necessary essentially to take account of the time shift 
and the invalidity of the first value. 

The practically relevant method of an interrupt-controlled routine which moves the 
conversion into the read pauses is normally realized for a customary microcontroller. The first 
variants would lead to a considerably increased time requirement. It is furthermore assumed 
that the interrogation and the processing are effected in the service routine of the timer 
interrupt. 
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inx. *p_adc, adcj/alue, upper^iimit, love*:_]Lin»it, *de_ready; 
int -adc_*rray t4096) t w 

void hacdwaro_thread roadADC () 
( 

irvt x - o; 
whil«< x < 4096 ) 
f 

if ( adc_ready 1 ) 
f 

adc_Value - *p_adc;. // Access to AD converter 

if( adc_value > upper^limit II adc_valuo < aover_aitait ) 
out_ox_cange() ; // call to exception routLn« 

adc^arraylx-M-) x; // ind^x information 

adc_arraytx++J * adc_valuo* // and adc value are stored 

) • 

> 

) y 

Fig. 2-2: C source code for ADC program 



It seems a likely supposition that, for application parts of this type, UCBs can likewise serve 
for supporting peripheral controller elements. The UCB can be correspondingly programmed 
both in a structural manner and in a sequential manner in a (software) high-level language - 
presupposing that a compiler is present which controls the PDSP translation. Fig. 2-2 
specifies the algorithm for taking up 2048 AD values, storing the respective value with 
additional index information and effecting comparison with regard to exceeding or 
undershooting limits in C: 

A compiler which effects optimization for the UCB architecture could translate this source 
code taking account of the new instructions into the following assembler code: 
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Fig. 2-3: Generation of the assembler code by compiler effecting optimization 
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The illustrated generation was carried out under various assumptions that must be specifically 
explained. Firstly, the condition specified in the C code that the system can run through the 
loop only when the ADC_READY signal is present is completely absent in the assembler 
code. It is assumed in this respect that the condition, which virtually constitutes a trigger, can 
be converted into an enable signal for the clock by the compiler (in this respect, also see 
fig. 2-1). This enable signal controls the acceptance clock for the UCB and thus corresponds 
to a trigger. If this assumption is impermissible, then all the instructions have to be made 
dependent on the ADC_READY signal, which is possible in principle, but costs very many 
comparison resources. 

Moreover, there are conditional interrupt calls (intxx) present in the assembler code, which 
can be mapped onto the signal generation in a UCB. This signal generation to an upstream 
stage must be buffer-stored there and processed, for instance by means of an interrupt call to 
the actual processor. 

Under these preconditions, the following structure arises in a UCB: 
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Fig. 2-4: Mapping ADC routine in UCB 
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This example shows the fundamental transferability of routines for intelligent peripherals to 
the concept of UCBs, where a number of assumptions had to be made in particular for the 
usability of procedural compilers. In particular, the system developer must declare the parts 
which are in each case intended to run in a UCB as independent threads (in the C example 
with the aid of the new keyword hardware_thread), while the compiler itself is required to 
translate this for a UCB. 

2.4 Summary 

The aim of this concept was to introduce a new architecture for field programmable logic 
which can simultaneously be integrated in microcontrollers and microprocessors and can be 
loaded by means of a sequential instruction stream with the aid of the PDSP algorithm 
(Procedural Driven Structural Programming) already specified. This architecture is 
distinguished by the introduction of a newly structured hardware optimized for the scope of 
application. 

By way of example, it was possible to show in this case the form in which the UCBs can be 
programmed and operated. This structure can be operated both in standalone fashion and in 
conjunction with microcontrollers, and produces very good results, especially in the context 
of a co-design, by close matching to the architecture and method of operation of processors. 
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